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TOWARD RELIABLE OPERATION 
OF MINICOMPUTER-BASED TERMINALS ON A TIP 


The present protocol for communication between a TIP and 
attached terminals requires character-oriented transmission and 
provides for no error control. In the design of this protocol, it was 
apparently assumed that the majority of terminals attached to a TIP 
would be interactive, be normally used in a character-by-character 
mode both for transmission to and from the terminal, and normally 
support a human user who would in effect be in the communication loop. 
The human user would thus be in a position to detect any significant 
telecommunication-induced errors both by direct observation of the 
character stream and, more importantly, by examining the computer 
output in the context of his ongoing interaction. 


The effectiveness of this means for error detection and 
initiation of corrective measures when necessary is not adequate in 
the following cases: 


a. For terminal-TIP communication at a medium or 

higher data rate (say 1200 bps or higher) it is quite possible 
that the human will skim computer output and not be an 
effective character-—by-character error detector. In 
particular, when both user input and computer output 

contain numerical data it is possible that significant 
undetected errors could occur. 


b. For terminals located at a distance from the TIP 

and connected either by a private line or the switched 
network more errors may be introduced than with a 
terminal local to the TIP (see Note 1). When a large 
number of user terminals are connected to TIP’s through 
telecommunications facilities, whether within a single 
organization or, even more likely, when users and user 
groups not needing the full TIP capability are connected 
to a remote TIP, this problem may arise. 
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c. For terminals containing a substantial amount of logic, 
including possibly a minicomputer, a human user is very 
likely not in the direct terminal-TIP communications loop. 
This case is important, since both alphanumeric and full 
graphics terminals containing minis are now becoming 
popular. 


d. An interesting potential application of the network is to 
provide support for minicomputers used for process 

control and other laboratory measurement functions. In 
providing software support for such minis as well as 
acquiring data from them usually there is no human user 

in the communication loop. 


e. A number of sites already offer a remote job entry 
service. Although the present sites assume that the unit 
record devices such as card readers and line printers are 
files within a multiprogrammed system at another site, it 
appears natural that remote batch terminals be attached 
to the network through TIP’s. Here again, there would be 
no human in the loop between the terminal and the TIP. 


In addition to some degree of error control on these types of 
terminal loops, it may be desirable to provide for block-oriented data 
transmission, at least for terminals of types (d) and (e) and possibly 
(c) above. It is possible that error control utilizing block 
transmission can be superimposed on the present TIP-terminal 
communication protocol. Data blocks, including error control and block 
delimiting information, can be multiples of a single character in 
length. The communication channel would still not be as fully utilized 
as for conventional synchronous block communication, since start and 
stop bits for each character would need to be transmitted. This loss 
is not substantial and does occur now for 2000 bps TIP-terminal 
communication. 


There are at least two ways to implement such a protocol on 
top of the existing TIP-terminal communication protocol. In both 
cases, the remote terminal would have to handle both originate and 
receive error and block control procedures: 


a. Through an addition to TIP software, the controlled 
communication loop could terminate in the TIP, thus 
providing error control only where it is most needed, 
between the TIP and the terminal. This, however, would 
involve additional TIP software and a block buffering 
capability which may put an excessive load on the TIP. 
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b. The other end of the block transmission error control 
loop could be in the serving host system, either in an 
applications program or in system support software. 


If the remote end of the block transmission error control loop 
is in the serving host, then this software could possibly be used for 
host-to-host, end-to-end error control in addition to 
host—host-terminal end-to-end error control. For host-to-host 
communication, however, there would be a slight loss in efficiency due 
to the imbedded character-oriented format, unless an option were 
provided in which start/stop bits were not required. 


Note 1: The most recent published data concerning data transmission 
error performance of the switched telecommunications network is 
provided in the 1969-70 Connection Survey conducted by Bell 
Laboratories. The results are published in The Bell System Technical 
Journal, Vol. 4, No. 50, April 1971. In this survey, 12 receiving and 
92 transmitting sites in the U.S. and Canada were used with standard 
Bell System Dataphone datasets used at both ends. At both 1200 and 
2000 bps, approximately 82% of the calls had error rates of 1 error in 
10*5 bits or better, assuming an equal number of short, medium, and 
long hauls. 


The results of this survey for low-speed, start/stop data 
transmission at rates up to 300 bps indicate a character error rate of 
1 error in 10^4 characters or better on 77.6% of all calls made within 
the survey. It is interesting to note that only 48.3% of the low-speed 
data tests completed were error-free. These tests were nominally 40 
minutes in length. 


For voice grade private line data channels, the Bell System 
technical reference, "Transmission Specifications for Voice Grade 
Private Line Data Channels," dated March 1969 reports "When a Bell 
System dataset is combined with the recommended channel, the expected 
long term average error rate of the system is 1 error in 10%5 bits or 
better during normal transmission conditions. " 
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